At 05:28 +0300 on 21/07/1999, tjk@tksoft.com wrote:
> The table is stored in one chunk of a file, and when
> postgres modifies it, it takes a long time because
> it has to do a heck of a lot of seeking and modifying
> in the file. This ends up being very time consuming.
>
> When you use a separate table for the field you are
> isolating the field to its own file, which means
> that when it's modified only a much smaller file
> needs to be worked on.
This will give a penalty in the selects, however. When you split a table
into two, you have to have a relation between the field you separated and
the original table, and from then on, you can see them together only using
a join. A join takes more time than a search on one table.
I think that update is slow, because it has to read each record, and write
it in its new form in the end of the file. It does sequential scanning plus
jump to the end of the file and writing. That's essentially what you said,
too. In addition, it has to re-index each new entry.
But in my opinion, the chance to make this faster is to select the new
values into a new table, drop the old table, rename the new table, and add
indices after that. If your table is called A:
CREATE TABLE B ...; -- Same schema and constraints as A
INSERT INTO B SELECT f1, f2, 'unknown', f4... FROM A; -- Note new value
DROP TABLE A;
ALTER TABLE B RENAME TO A;
CREATE INDEX .....; -- Recreate the indices
When defining the table, don't use SERIAL and PRIMARY KEY, as these create
sequences and indices. You would do better to control these yourself, so as
not to break the sequences used, and not to create an index before all
values are inserted.
One last comment: indices always accelerate retrieval, at the expense of
slowing inserts and updates.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
